1. Field of the Invention
The present invention relates to web browser control of audio operations for voice enabled web applications within a hypertext markup language (HTML) and hypertext transport protocol (HTTP) framework.
2. Description of the Related Art
The evolution of the public switched telephone network has resulted in a variety of voice applications and services that can be provided to individual subscribers and business subscribers. Such services include voice messaging systems that enable landline or wireless subscribers to record, playback, and forward voice mail messages. However, the ability to provide enhanced services to subscribers of the public switched telephone network is directly affected by the limitations of the public switched telephone network. In particular, the public switched telephone network operates according to a protocol that is specifically designed for the transport of voice signals; hence any modifications necessary to provide enhanced services can only be done by switch vendors that have sufficient know-how of the existing public switched telephone network infrastructure.
FIG. 1 is a diagram illustrating the existing public switched telephone network. As shown in FIG. 1, the public switched telephone network 10 includes a wireline subnetwork 12, a wireless subnetwork 14, and a time division multiplexed (TDM) backbone subnetwork 16 configured for transporting voice data and other data between user devices 18 according to the existing public switched telephone network protocols. The subnetwork 16, for example, includes interexchange trunks for transporting voice data between interexchange carriers and/or local exchange carriers.
As shown in FIG. 1, the wireline subnetwork 12 includes telephony application servers 20 configured for providing voice applications 22 such as subscriber profile management, voice mail, call forwarding, etc. for the user devices 18a, 18b, and 18c coupled to the wireline subnetwork 12. As recognized in the art, the telephony application servers 20 include advanced intelligent network (AIN) components such as services control point (SCP) directories and service nodes (SN) configured for controlling the telephony applications 22. The wireline subnetwork 12 also includes telephony access services 24 configured for providing the user devices 18a, 18b, and 18c access to the wireline subnetwork using, for example, analog twisted pair connections or ISDN connections to a central office. The user devices 18a, 18b, and 18c, illustrated as a cordless telephone 18a, a fax machine 18b having a connected telephone, and an analog telephone 18c, are referred to herein as xe2x80x9cskinny clientsxe2x80x9d, defined as devices that are able to interface with a user to provide voice and/or data services (e.g., via a modem) but cannot perform any control of the application 22 or the protocol used to interface with the wireline subnetwork 12.
The wireless subnetwork includes wireless application servers 26, and wireless access services 28 for providing wireless voice and data services to the wireless user devices 18d, 18e, and 18f. The wireless user devices 18d, 18e, and 18f, illustrated as a cellular telephone (e.g., AMPS, TDMA, or CDMA) 18d, a handheld computing device (e.g., a 3-Com Palm Computing or Windows CE-based handheld device) 18e, and a pager 18f, interact with the wireless application 30 based on respective wireless protocols controlled by the wireless access services 28. The wireless application servers 26 control wireless services such as home location register (HLR) management, and service node (SN) telephony applications. xe2x80x9cTiny clientsxe2x80x9d are distinguishable from skinny clients in that the tiny clients tend to have even less functionality in providing input and output interaction with a user, and may not be able to send or receive audio signals such as voice signals at all. Examples of tiny clients include wireless user devices 18d, 18e, and 18f, as well as function-specific terminal devices. Note that tiny clients tend to be one-way (receive-only or transmit-only) devices.
In both cases, however, both skinny clients and tiny clients have no control of the respective applications 22 and 30 that are running within the respective networks. Rather, the applications 22 and 30 are executed exclusively by the servers 20 and 26. Moreover, both skinny clients and tiny clients have no control of the access protocol used to access the respective subnetworks 12 and 14; hence, the skinny clients and tiny clients are currently incapable of initiating access to another network using an alternative protocol, for example Internet protocol (IP). Consequently, the skinny clients and tiny clients rely exclusively on the service nodes of the servers 20 and 26 to provide the voice application services programmed in the applications 22 and 30, respectively. Although this exclusive control of the applications 22 and 30 by the servers 20 and 26 is advantageous in maintaining control over quality of service and reliability requirements, the applications 22 and 30 can only be developed and maintained by programmers having sufficient know-how of the public switched telephone network infrastructure. As a result, programmers familiar with open standards such as IP are unable to provide contributions in enhancing the applications 22 and 30 due to the limitations of the public switched telephone network paradigm.
FIG. 2 is a diagram illustrating the web client-server paradigm of an open standards-based IP network 40, such as the World Wide Web, the Internet, or a corporate intranet. The IP network 40 provides client-server type application services for clients 42a and 42b by enabling the clients 42 to request application services from remote servers using standardized protocols, for example hypertext transport protocol (HTTP). For example, the client 42a is a stand-alone personal computer or workstation that has its own application 44 for providing its own application services. The client 42a can access a remote web application server 46 that executes a different set of application services 48 via an IP-based packet switched network 50 using either remote access services 52 or local area network access services 54, if available. Similarly, the client 42b having only a browser 56 can also enjoy the services of the applications 44 and 48 by accessing the respective computers 42a and 46.
The clients 42a and 42b, referred to herein as xe2x80x9cfat clientsxe2x80x9d and xe2x80x9cthin clientsxe2x80x9d, respectively, have the distinct advantage that they can initiate requests using IP protocol to any connected web server 46 to execute part or most of the applications 48 on behalf of the clients. An example of a fat client 42a is an e-mail application on a PC that knows how to run the application 44 and knows how to run the IP protocols to communicate directly with the messaging server via the packet switched network 50. An example of a thin client 42b is a PC that has a web browser; in this case, the web browser 56 can use IP protocols such as HTTP to receive and display web pages generated according to hypertext markup language (HTML) from server locations based on uniform resource locators (URLs) input by the user of the PC.
Hence, the web server paradigm enables the clients 42 to access any web server on the IP network 40. Moreover, the use of open protocols such as HTTP and HTML enable any client 42, regardless of its configuration, to access an HTML web page from a server that has no knowledge of the configuration of the requesting client; if the HTML web page received by the client includes information such as a specific HTML tag that is not recognizable by the browser 56, the browser 56 can merely ignore the unrecognized HTML tag.
Efforts at extending the voice applications 22 and 30 from the public switched telephone network to the IP network 40 have had limited success, primarily because the telephone protocols used in development of the applications 22 and 30 do not operate under the same paradigm as the IP network 40. For example, the telephony applications 22 and 30 are state aware, ensuring that prescribed operations between the application servers 20 or 26 and the user devices 18 occur in a prescribed sequence. For example, operations such as call processing operations, voicemail operations, call forwarding, etc., require that specific actions occur in a specific sequence to enable the multiple components of the public switched telephone network to complete the prescribed operations.
The applications 44 and 48 running in the IP network 40, however, are state-less: the applications 44 and 48, in response to reception of a specific request in the form of a URL from a client 42, instantiate a program configured for execution of the specific request, send an HTML web page back to the client 42, and end the program that executed the specific request. Although state information may be passed between the browser 56 and a web application 48 using a data file referred to as a xe2x80x9ccookiexe2x80x9d, some users prefer not to enable cookies on their browser 56; in addition, the passing of a large amount of state information as would normally be required for voice-type applications between the browser 56 and the web application 48 would substantially reduce the bandwidth available for the client 42.
In addition, HTML does not provide the type of control that is necessary to support voice applications. Specifically, HTML was designed as a set of specifications for embedding instructions within text that specifies to a browser how the text should be presented to the user. Hence, HTML is particularly effective for presenting on a browser a web page having text and image data, or forms data. However, HTML does not provide good media control: if instructions are embedded within an HTML page, there is no guarantee that a browser will execute the embedded instructions as intended by the web page designer.
Hence, efforts have been made to integrate the telephony applications 22 and 30 directly onto the IP network 40 by developing protocol translators that provide a termination between the telephony applications servers 20 and 26 and the web application servers 46. One such proposal is referred to as voice over IP, where telephony data from the telephony applications 22 and 30 are repackaged into IP packets for transmission across the IP network 50. These efforts, however, still require programmers who have substantial know-how of the telephony applications 22 and 30 and the public switched telephone network infrastructure. Moreover, the repackaging of telephony data into IP packets creates substantial problems in transmission of the telephony data, since the transport of IP data packets is not sequential and synchronous, as required for the voice applications.
Another attempt at performing voice applications over an IP network involves rewriting the telephony applications 22 and 30 as scripts in extensible markup language (XML), and sending the XML scripts over the IP network to an interpreter that is coupled to a telephone. The interpreter then plays the received XML scripts for the telephone. However this approach merely transfers some application functionality from the telephony applications 22 and 30 to the interpreter, and still requires telephony application engineers to write XML scripts of the applications 22 and 30. Hence, the IP network is used only for transporting the XML scripts, and does not take advantage of the open standards-based flexibility of the IP network that has provided enormous growth in web infrastructure and Internet commerce.
An additional concern in attempting voice applications over an IP network involves providing backwards compatibility for the existing devices 18 configured for communication via the public switched telephone network 10. Unlike the clients 42 in FIG. 2, the skinny clients 18a, 18b, and 18c and the tiny clients 18d, 18e, and 18f cannot perform any application control functions. Hence, any proposed system that extends the voice applications 22 and 30 to the IP network 40 will have limited success in the marketplace unless the skinny clients and the tiny clients are able to enjoy the same type of services as the clients 42.
There is a need for an arrangement that enables voice applications to be implemented on an IP packet switched network using the open standards-based flexibility of the IP network.
There is also a need for an arrangement that enables voice applications to be implemented using HTTP and HTML open standards, enabling development of voice applications by individuals that do not have expertise in the public switched telephone network. For example, there is a need for arrangement that enables voice applications to be designed by web programmers.
There is also a need for an arrangement that enables voice applications to be implemented using an IP network, without the necessity of the public switched telephone network.
There is also a need for an arrangement that enables unified voice messaging services to be provided via an IP network to any device having a browser, regardless of the configuration of that browser.
There is also a need for an arrangement that enables a web browser to provide advanced audio control features to enable voice enabled web applications from a web server to be presented to a user of the web browser.
There is also a need for an arrangement that enables user devices that lack application control functionality to enjoy voice application services using an IP network, without substantial modification to the user devices.
These and other needs are attained by the present invention, where a web browser receives an HTML page having an XML element that defines data for an audio operation to be performed by an executable audio resource. The web browser selectively executes the audio operation based on whether the web browser detects the presence of the executable audio resource. If the web browser does not have the executable audio resource, then the web browser ignores the XML element, and merely presents any other recognized HTML tags. However if the web browser has access to an executable audio resource that understands the XML element, then the web browser executes the audio operation based on enhanced audio control specified by the XML element. Hence, a web browser can be used to provide enhanced voice control for voice enabled web applications, merely by possession of an executable audio resource that recognizes the XML element that specifies the enhanced audio control required for the audio operation to be performed.
In addition, the web browser provides voice services for user devices that lack application control functionality by acting as a proxy browser for the user devices. In particular, the proxy browser is executable within an interface between a public switched telephone network component and the IP network. The proxy web browser, based on capabilities information for a corresponding user device, is configured for selectively ignoring received HTML tags that specify media content to be displayed, and selectively executing the audio operations specified by the XML element. Hence, the proxy browser supplies to a user device only the content that the user device is capable of interpreting, for example audio signals for an analog telephone, or text for a pager or a facsimile machine.
According to one aspect of the present invention, a method is provided in a proxy browser for executing a web browser according to hypertext transport (HTTP) protocol. The method includes receiving a hypertext markup language (HTML) page by the web browser, from an HTTP connection, having an HTML tag and at least one extensible markup language (XML) element defining data for an audio operation to be performed by an executable media resource, determining capabilities of a user device configured for receiving prescribed media information from the device, and selectively executing by the executable media resource at least one of the HTML tag and the audio operation for delivery of the prescribed media information to the user device, based on the determined capabilities of the user device. The reception of an HTTP page that includes XML element defining data for an audio operation to be performed enables the web browser to receive advanced audio control functions from a web server via an HTTP connection, without any modification to the web browser. Moreover, the selective execution of the HTML tag and the audio operation based on determined capabilities of the user device ensures that user devices receive as much media content as the devices are configured to receive; hence, if a user device does not have a certain capability, the corresponding operation is disregarded, ensuring that the user device has access to the media services without suffering from incompatability problems. Another aspect of the present invention provides a processor-based device configured for executing audio operations based on a hypertext markup language (HTML) page received from a server according to hypertext transport protocol (HTTP). The device includes a web browser configured for selectively interpreting the HTML page, the HTML page including at least one of an HTML tag and an XML element that defines data for an audio operation to be performed for a user device. The device also includes a media resource configured for selectively executing at least one of the audio operation and the HTML tag based on determined capabilities of the user device. The web browser provides an HTTP connection for the user device, enabling the user device to access application services that previously were not available to the user device, including web-based audio services such as voice messaging. Moreover, the media resource ensures that the user device does not receive information from the HTML page that the user device cannot process, ensuring that any user device can access an HTTP connection, regardless of its corresponding capabilities.
Additional advantages and novel features of the invention will be set forth in part in the description which follows and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The advantages of the present invention may be realized and attained by means of instrumentalities and combinations particularly pointed out in the appended claims.